# GPT-5.6 三模型横评 - 全栈项目实测

> 三大 AI 编程旗舰模型同场竞技，一把梭开发全栈足球游戏项目

刚刚，OpenAI 正式发布了 GPT-5.6 系列模型，包含 Sol 旗舰、Terra 均衡和 Luna 轻量三个版本。

![](https://pic.yupi.icu/1/image-20260710102644422.png)

这是 OpenAI 继 GPT-5.5 之后最大的一次模型更新，官方称 Sol 是 **有史以来最强模型**，在多个编程能力测评上超越了 Claude Fable 5！

恰好同一周，马斯克旗下的 SpaceXAI 也放出了 Grok 4.5，号称 Opus 级别的模型；而 Anthropic 之前被封禁的 Claude Fable 5 也在 7 月 1 号重新上线。

这下，三家的新旗舰模型凑齐了，这种难得的机会，必须得安排一次大乱斗！

正好这三个模型在 Cursor 里都能用了，我干脆让它们同时开发同一个项目，用实际的 AI 编程能力来分个高下。

![](https://pic.yupi.icu/1/image-20260710101735638.png)

开始之前，先聊聊这次 GPT-5.6 到底更新了什么。



## GPT-5.6 更新了什么？

GPT-5.6 这次最大的变化是把模型分成了 3 个档次：

| 模型  | 定位           | 输入价格（每百万 token） | 输出价格（每百万 token） |
| ----- | -------------- | ------------------------ | ------------------------ |
| Sol   | 旗舰，最强智力 | $5                       | $30                      |
| Terra | 均衡，日常工作 | $2.50                    | $15                      |
| Luna  | 轻快，最低成本 | $1                       | $6                       |

Sol 的定价跟 Opus 4.8 差不多（输入 5 刀、输出 30 刀），但比 Fable 5（输入 10 刀、输出 50 刀）便宜了整整一半。

跑分方面，GPT-5.6 Sol 在 Terminal-Bench 2.1（终端编程 + Agent 工作流能力）上拿到了 88.8%，Ultra 模式更是达到了 91.9%，把 Fable 5 的 83.4% 和 GPT-5.5 的 83.4% 都甩在了身后。

![](https://pic.yupi.icu/1/image-20260710101910897.png)

除了模型本身，这次 OpenAI 在产品层面也有大动作，Codex 正式合并到 ChatGPT 里了！

![](https://pic.yupi.icu/1/1783642205423-e6d8b21a-bd10-4ee9-a40e-0bf58b24b25b-20260710113955972.png)

在左上角可以切换 Work 和 Codex 两个模式：

![](https://pic.yupi.icu/1/1783643141313-5d69bf30-2618-4b2e-9c8c-11e6d5541280-20260710113956124.png)

在 Codex 中，可以直接使用 GPT 5.6 全系列模型，自由设置推理强度：

![](https://pic.yupi.icu/1/image-20260710102330452.png)

另外还新推出了「站点」功能，可以用自然语言描述需求，AI 帮你生成网页应用并直接托管上线，后面带大家玩玩~

![](https://pic.yupi.icu/1/image-20260710105835836.png)

模型能力方面，我觉得最值得关注的有 3 点。

**1）Ultra 模式 - 内置多 Agent 协作**

这个跟 Opus 4.8 的动态工作流类似，但 OpenAI 把它做成了一键开关。

开启 Ultra 后，模型会自动把任务拆解成多个子任务，同时派出多个子 Agent 并行处理，中间还能互相协调。

相当于以前你得手动搭一个多 Agent 编排框架才能干的事，现在模型内置了。但代价可想而知，token 的消耗会翻好几倍。

**2）Max 推理模式**

和 Ultra 不同，Max 模式就是单纯给模型更多的思考时间，类似 Claude 的 Extended Thinking。适合那些需要深度推理但不需要并行处理的场景。

**3）更智能的 Prompt 缓存**

支持显式缓存断点和 30 分钟最低缓存生命周期，缓存命中时输入成本打一折。对于跑长时间 Agent 任务的开发者来说，应该能够大幅节约成本。

![](https://pic.yupi.icu/1/01_GPT-5.6%25E4%25B8%2589%25E5%25A4%25A7%25E8%2583%25BD%25E5%258A%259B%25E4%25BA%25AE%25E7%2582%25B9%25EF%25BC%259AUltra%25E5%25A4%259AAgent%25E3%2580%2581Max%25E6%25B7%25B1%25E5%25BA%25A6%25E6%258E%25A8%25E7%2590%2586%25E3%2580%2581Prompt%25E7%25BC%2593%25E5%25AD%2598_compressed_v2.png)

看到这里，你是不是也对 GPT 5.6 充满期待了？

不过 GPT 5.6 也有一些争议。安全评估组织 METR 在官方博客中披露，GPT-5.6 Sol 在跑分测试中存在「作弊」行为，利用评测系统的 Bug 来刷分，被评为历史上检测到的最高作弊率。OpenAI 自己发布的 System Card 也承认 Sol 有过度主动的倾向，会未经授权就执行一些操作。

所以跑分数据看看就好，很多模型发布时，跑分没输过，实测翻皮水……

下面咱们还是来实战测试一下。



## 让 Cursor 自动并行测试

由于要同时测试多个模型，我选择用 Cursor 的子 Agent 能力来做测试。

给 Cursor 发一段提示词，它会帮我同时启动 3 个子 Agent，分别用 GPT-5.6 Sol、Claude Fable 5 和 Grok 4.5，用 **同一段提示词** 在各自的目录里开发同一个项目。

这样一来，三个模型可以使用完全相同的 Harness 工程环境，包括相同的工具、MCP 和 Skills、同样的上下文。我还在提示词里运用了 Loop Engineering 的思想，要求模型写完就自测、发现 Bug 就修复、循环迭代直到满意为止。

![](https://pic.yupi.icu/1/image-20260710103421135.png)

这次我让 AI 开发的是一个「足球对战网页游戏」，名字叫 **2066 决战世界杯**。

玩家操控一支 5 人球队和电脑人机对战，包含 10 个功能需求：物理引擎、AI 对手、比赛系统、用户排行榜、战绩统计面板等等。

![](https://pic.yupi.icu/1/image-20260710110116017.png)

为什么选择足球游戏作为测试案例呢？

因为它能全方位考察模型的能力：

- 物理引擎要求模型具备向量计算和碰撞检测的数学能力
- 电脑人机要求模型能设计状态机和决策逻辑
- Canvas 渲染考验游戏循环和帧率控制
- 后端 API 和排行榜考验全栈工程能力

而且最终效果好不好，打一把游戏就知道了，不需要逐行看代码~

提示词中，我不对技术栈做限定，由模型自己选择。比如物理引擎是从 0 开始写还是用现成的库、前端用什么框架、数据库选什么，全部交给 AI 自主判断，而且全程零人工干预。



## 开发过程对比

在 AI 开发的过程中，只有 Claude Fable 5 在动手写代码之前先列出了一份完整的任务计划，逐条规划要实现哪些模块、用什么方案。

GPT-5.6 Sol 和 Grok 4.5 则是想了想就直接开干了，边写边调。

![](https://pic.yupi.icu/1/image-20260710105402348.png)

在提示词的引导下，三个模型都使用了 Cursor 内置的浏览器来自主测试效果：

![](https://pic.yupi.icu/1/image-20260710105513163.png)

最后，三个模型全部完成了 10 个功能的开发，但速度差异非常明显：

| 模型           | 总耗时    | 修复轮次   |
| -------------- | --------- | ---------- |
| GPT-5.6 Sol    | 9.2 分钟  | 2 次       |
| Grok 4.5       | 10.1 分钟 | 5 次       |
| Claude Fable 5 | 19.5 分钟 | 未详细记录 |

GPT-5.6 Sol 最快交卷，而且只修了 2 轮 Bug 就跑通了。Fable 5 花了将近 20 分钟，大概是 thinking 模式花了更多时间在规划上。说明在这种一把梭的场景下，快速动手迭代可能比详细的前期规划更有效。

好了，下面咱们看看成品效果。



## 成品效果对比



### GPT-5.6 Sol

打开网站后，直接进入到赛前设置界面，不需要先登录就能玩，这个体验设计我觉得挺好的。

队名给我整乐了，什么霓虹龙队、量子猎鹰，怎么又土又潮的。

凭借着对自己手速的自信，我选了中等难度。

![](https://pic.yupi.icu/1/1783646727877-176ed69a-3126-4908-8886-6fdfdddacee5.png)

进入到比赛界面，UI 风格还可以，球场基本还原了标准布局，虽然少了两个罚球区弧线，但不影响游戏。

游戏的操作体验很顺畅，踢球方向也没问题，但是人机的表现让我有点难绷……

我开局站着不动 20 秒，想看看人机会不会有什么战术配合，结果对方前锋一直在顶撞我的后卫，同时疯狂对轰我的守门员，守门员倒是不动如山，愣是一个球没进。

好家伙，你俩打乒乓球呢？

![](https://pic.yupi.icu/1/1783647330206-bb64786d-95d9-41e5-9d53-4fb42ffdd9da.png)

而且 AI 不会主动组织进攻，基本就是追着球跑。更搞笑的是下面这个名场面，两个自家的红方球员扭打在一团，何意味？

![](https://pic.yupi.icu/1/1783646934441-fabe029a-30bc-4f09-ad66-6765a9988805.png)

我尽了自己的全力，打完了一整场中等难度，结果是 0 比 0 收场，人机的防守真是密不透风。

![](https://pic.yupi.icu/1/1783646990995-cc740553-5e74-4a26-9155-b94f1875b3d2.png)

我又试了一把简单难度。这次人机的水平明显下降了，我方前锋「李佛脚」单枪匹马直接破门，拿下一分！

![](https://pic.yupi.icu/1/1783647469882-4dc1950a-62b4-4bcf-b65a-e212c8c49db6.png)

比赛结束，只有登录才能统计成绩。登录页面的风格挺不错，虽然一眼 GPT，但还是有未来感的。

![](https://pic.yupi.icu/1/1783647079978-8b36af2c-829e-439d-8bba-db2c42fa6017.png)

战绩统计面板做得也挺完整，胜率、难度分布、近场走势都有：

![](https://pic.yupi.icu/1/1783647118172-7dc754c2-cf81-4927-b859-e93a298e6e46.png)

排行榜页面没什么好说的，中规中矩：

![](https://pic.yupi.icu/1/1783647136681-5cdb9ef0-f629-4844-b8ec-777f8af43454.png)

不过移动端就拉胯了，足球场被严重挤压，完全没法玩！

![](https://pic.yupi.icu/1/1783649199142-be627e8b-a1e7-4d8b-8ada-8a18c600575f.png)



### Grok 4.5

Grok 4.5 开发的网站上来先要登录，而且登录界面的配色有点儿魔幻，很难让人联想到这是一个足球游戏。

![](https://pic.yupi.icu/1/1783647544967-ad6015f7-dcdc-4a0f-945e-ae93c3e27b8b.png)

进入赛前设置页面，我方队名「银河战舰」、对手队名 「星际联队」，这名字的确很符合 SpaceX 的模型了。

右侧直接就是排行榜，没见过这么会偷懒的……

![](https://pic.yupi.icu/1/1783647588899-c135c1ab-5362-419a-bf26-36c8c5307450.png)

进入比赛之后，这个球场的图形…… 什么成分我就不多说了吧？

中等难度下，我方球员笨得可怕。你管下面这位叫守门员？

![](https://pic.yupi.icu/1/1783648020795-d1809bda-6c3c-4e36-babf-a3f6e9e494e1.png)

果然没过多久，我方就被破门了。TNND 我的几个队友全体挂机，只留下守门员和对手赵云单挑。

![](https://pic.yupi.icu/1/1783648076215-344330eb-541c-4c4c-bef2-b94a0b24c436.png)

游戏的换人逻辑也很不顺畅，经常给我换到离球最远的那个人身上，点好几次才能切换到我想控制的球员。

最后被踢了个 4 比 0，而且一直是被对方同一个人反复破门。这将是我李佛脚职业生涯上的耻辱柱 &%￥*……

![](https://pic.yupi.icu/1/1783648162915-172f786b-a771-4d8d-8f50-14db232bb236.png)

![](https://pic.yupi.icu/1/1783647838129-52fd0932-b7f5-42d8-ba0f-08f2731735b6.png)

赛后的战绩统计做得还挺完整，但就是太偷懒了，谁家把赛前设置和赛后统计放在一个页面啊？

![](https://pic.yupi.icu/1/1783647910762-5718a633-f2b9-4d21-bec8-db3b50121c1b.png)

再看看移动端，足球场能够完整展示，但空间太小，布局一般：

![](https://pic.yupi.icu/1/1783649238383-14287cf2-db7c-46e8-a9f0-c29191bacb88.png)



### Claude Fable 5

Claude Fable 5 开发的网站同样需要先登录才能玩，登录页面的整体风格中规中矩吧。

![](https://pic.yupi.icu/1/1783648268430-11dab7ed-5cbc-499f-8a8c-c9a7e70562db.png)

来到赛前准备界面，这 Emoji 用的让我有点儿难受了，界面也太刻板，没什么游戏的感觉：

![](https://pic.yupi.icu/1/1783648312035-16c106ec-7cdd-4e0b-b03c-d30d1336d695.png)

进入比赛，这个球员的造型给我蚌埠住了…… 小只因 🐦？

不过球场的布局倒是三个模型里最标准的，中圈、禁区、罚球区弧线都有，这点给好评。

![](https://pic.yupi.icu/1/1783648663747-6d91fbbc-aa30-4e70-943d-ff0a9ba2c562.png)

结果没想到，整个游戏体验极差！

足球会经常瞬移，好像每个球员都有飞雷神术一样，我玩了 1 分钟就受不了了。

比如你看现在，球在对方球员的前面：

![](https://pic.yupi.icu/1/1783648857986-4d1edca9-1496-494c-80b1-096690b34bc4.png)

一转眼，球直接瞬移到对方球员身后了！

不是哥们？挑球也没你这么挑的啊？

![](https://pic.yupi.icu/1/1783648879116-db67afeb-0997-4cd8-94e8-987325fcad01.png)

我直接就是一个放弃比赛，给我玩恶心了…… 你管这叫 Claude Fable 5？

![](https://pic.yupi.icu/1/1783648437353-bcb6da92-14ac-45f3-a44a-e0f9422d8d47.png)

个人战绩页面也是中规中矩，让我怀疑模型是不是降智到 Opus 4.8 了：

![](https://pic.yupi.icu/1/1783648455388-51a72215-1fa2-46fb-904a-0710b92c095f.png)

最后看看移动端，倒是三个里面体验最好的，球场完整显示、布局合理，有虚拟摇杆和操作按钮：

![](https://pic.yupi.icu/1/1783649281625-fb60121f-743b-4345-8b7b-e4ab9d58b6ca.png)



## 代码质量对比

游戏体验聊完了，再来看看代码层面的差异。

技术选型方面很有意思，三个模型不约而同都选择了手写物理引擎，没有一个用 matter.js 之类的现成库。可能是因为足球游戏的碰撞逻辑相对简单（都是圆形碰撞），手写几十行代码就能搞定，引入一个完整的物理库反而显得笨重。数据库方面 GPT 选了最轻量的 JSON 文件存储，Grok 和 Claude 都选了 SQLite。

虽然三个模型都实现了全部 10 个功能，但它们的工程实现风格差别很大。

| 模型           | 源码文件数 | 代码行数 | 物理方案     | 数据库         |
| -------------- | ---------- | -------- | ------------ | -------------- |
| GPT-5.6 Sol    | 5          | 683      | 手写圆形物理 | JSON 文件      |
| Grok 4.5       | 8          | 2,622    | 手写 2D 物理 | better-sqlite3 |
| Claude Fable 5 | 5          | 1,844    | 手写物理引擎 | SQLite WAL     |

GPT-5.6 Sol 只用 683 行代码就搞定了 10 个功能，代码密度极高。

![](https://pic.yupi.icu/1/image-20260710111618379.png)

Grok 4.5 拆了 8 个文件、2622 行，模块化做的比较好。

![](https://pic.yupi.icu/1/image-20260710111641087.png)

Fable 5 代码量排在中间，1844 行，但有个问题，核心游戏逻辑全堆在一个 33KB 的 `game.js` 里，可维护性比较差。

![](https://pic.yupi.icu/1/image-20260710112615563.png)

人机对手的实现上，三个模型都用了规则驱动的状态机方案，按球员角色（门将 / 后卫 / 中场 / 前锋）分配不同行为，通过难度参数来区分三档。

虽然实现思路高度一致，但实际效果差异很大，这说明 AI 的代码逻辑和运行效果之间还是有 gap 的。



## 综合排名

最终，这次测试下来 3 个模型的排名如下：

| 排名 | 模型           | 一句话评价                                             |
| ---- | -------------- | ------------------------------------------------------ |
| 🏅 1  | GPT-5.6 Sol    | 速度最快、代码最精简、操控流畅、能正常玩               |
| 🥈 2  | Grok 4.5       | 架构最规范、统计面板最好看，但换人逻辑和球场渲染有硬伤 |
| 🥉 3  | Claude Fable 5 | 球场最标准、移动端最好，但物理引擎翻车导致没法正常游玩 |

看到这个结果，你觉得意外么？

Claude Fable 5 在之前我做的全栈项目测试中一直是 UI 和代码质量的王者，没想到这次竟然垫底了。

我自己的理解哈，足球游戏这种场景跟普通的 CRUD 全栈项目完全不一样。它对物理模拟的实时性要求很高，球的位置每一帧都在变，碰撞检测的精度直接决定了游戏能不能玩。Claude Fable 5 的 thinking 模式可能花了大量时间在「想清楚架构」上，但在物理计算这种需要精确调参的场景下，反而不如 Sol 那种「快速写完、马上跑、发现问题就修」的 Loop 风格来得有效。

Sol 只修了 2 轮 Bug 就跑通了，Fable 5 虽然花了 20 分钟，但物理引擎依然有明显的瞬移问题。这说明花时间多不代表质量高，至少在这种需要快速看到效果的小游戏场景下，快速迭代验证比深度规划更管用。

这告诉我们：**最贵的模型效果未必最好，也未必最适合你的任务。** 还是得按自己的实际场景来选模型。

时间有限，就先给大家分享这次测试。

最后，结合我自己的使用体感，给大家一些模型选择的建议：

- 日常开发、一把梭小项目，选 GPT-5.6 Sol。代码精简、效率极高，价格只有 Fable 5 一半。
- 长任务、复杂架构设计，选 Claude Fable 5。不过它有点像让教授来做初中数学题，简单的事反而想复杂了，遇到需要快速验证效果的场景可能会水土不服。
- 预算有限，选 Grok 4.5。每百万 token 输入只要 2 美元、输出 6 美元，比 Sol 便宜 5 倍、比 Fable 5 便宜近 10 倍，架构设计也比较规范。之前很多人都不看好 Grok，但这次新出的 Grok 4.5 在 Cursor 论坛上的反馈明显好了很多，算是打了个翻身仗。



## 写在最后

不过说实话，就从这个例子来看，这三个模型写出来的游戏都还差了点意思。没有一个能称得上「有足球战术智能」的，要么不会主动进攻，要么队友集体挂机，要么球直接瞬移。

想让 AI 写一个真正好玩的游戏，目前还是得花精力在迭代反馈上，指望一把梭出精品还为时尚早。

不过这样也好，说明程序员暂时还不用担心被 AI 抢走游戏开发的饭碗。

![](https://pic.yupi.icu/1/%E7%A8%8B%E5%BA%8F%E5%91%98%E5%8E%8B%E5%8A%9B%E4%B8%8D%E5%A4%A7%E8%A1%A8%E6%83%85%E5%8C%85.jpeg)

通过这次横评可以看到，不同模型在 AI 编程方面各有各的特点，最贵的不一定最好，最快的也不一定最全面。还是得按自己的实际需求来选模型，而不是盲目追新。

如果你想继续了解更多 AI 编程模型和工具的选择技巧，可以阅读本教程编程工具板块的其他文章。